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Abstract 


Requirement Assurance is an act of requirement verification which assures the stakeholders that 
a product requirement has produced its "as realized product" and has been verified with 
conclusive evidence. Product requirement verification answers the question, "did the product 
meet the stated specification, performance, or design documentation?". In order to ensure the 
system was built correctly, the practicing system engineer must verify each product requirement 
using verification methods of inspection, analysis, demonstration, or test. The products of these 
methods are the "verification artifacts" or "closure artifacts" which are the objective evidence 
needed to prove the product requirements meet the verification success criteria. 

Institutional direction is given to the System Engineer in NPR 7 123.1 A NASA Systems 
Engineering Processes and Requirements with regards to the requirement verification process. 
In response, the verification methodology offered in this report meets both the institutional 
process and requirement verification best practices. 
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1 Introduction 


The verification process is an important, fundamental element in systems engineering (Ref 1 .) 
and critical to a successful closure of the project’s requirements. When the requirements are 
developed early in the project’s life cycle, the verification methods are defined. These methods 
used in verifying product requirements are inspection, analysis, demonstration and test (Ref 2). 
Requirement verifications are defined as proof of compliance with specifications. The resultant 
products of the verification methods are documents that contain the closure artifacts 
demonstrating proof of compliance. 

The Requirement Assurance (RA) verification process is built around the Verification 
Compliance Sheets (VCS) as seen in Appendix A. This process establishes an auditable 
verification trail concluding in the absolute verification of requirements and meeting the 
institutional guidance given in NPR 7123.1 A NASA Systems Engineering Process and 
Requirement (Ref. 3). This report articulates the RA process from its initial implementation until 
the final submittal of the Verification Compliance Document (VCD). 

1.1 Purpose 

The purpose of this report is to define the Requirement Assurance verification process 
establishing a proven product requirement verification methodology that meets NPR 7123.1 A 
guidelines which are applicable to any size project and works across all WBS levels. 

1.2 History 

The Requirement Assurance verification process described herein is adapted from the ARES 1-X 
project verification process. The ARES 1-X mission was selected as the first suborbital 
development flight test to help meet Constellation Program (CxP) objectives. The ARES 1-X 
was launched successfully on October 28, 2009, from the NASA Kennedy Space Center in 
Florida. 

1.3 Requirement Assurance Process Overview 

At each Work Breakdown Structure (WBS) level (system, element, subsystem, etc.), product 
requirements are defined and subsequently placed in the appropriate WBS level requirements 
document. At this time, the system engineer chooses the best verification method to verify each 
requirement. Once the requirement document is approved by the WBS level manager, the 
system engineer ensures the development and approval of a verification plan. This plan is 
created at each WBS level and details the Requirement Assurance verification process (Figure 1) 
and its execution at that level. 
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A 





Figure 1 - Requirement Assurance Verification Process 

A key to the success of Requirement Assurance is the Requirement Owners (RO). Requirement 
Owners are assigned by the WBS level project manager to specific requirements as subject 
matter experts. In addition, the ROs are responsible to ensure assigned requirements are verified 
in accordance with the verification plan and the Verification Matrix (VMX). 

The VMX is typically a spreadsheet that contains the requirement’s pre -verification data that is 
needed to perform the product requirement verification such as the verification scope 
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(requirement), success criteria, rational, and etc. Based on a small project size and project 
management approval, some system engineer practitioners have continued to populate the VMX 
with verification data and submitted it as the project’s VCD. 

Once the information in the VMX is approved or concurred with, the data can be transferred 
using the mail merge function to the Verification Compliance Sheet (VCS) which is typically a 
Microsoft Word document. Each row of the VMX spreadsheet is a requirement verification and 
after the mail merge the requirement verification now has its own VCS. The pre-verification 
data-filled VCSs are organized and bound together to create a verification workbook for each 
RO. At this time, the VCS are partially completed and are not an official VCS until completely 
filled out and approved. 

The RO workbook is an unofficial working level document given to the RO to record notes, 
results, data, and any information the RO deems necessary to support the verification of a 
product requirement. When the RO approves the verification artifact(s) and populates the VCS 
with final data, the RO submits the VCS to the system engineer for requirement verification 
approval. 

The system engineer places the approved VCSs into the appropriate WBS level Verification 
Compliance Document (VCD) and submits the VCD to the project for approval and baselining 
upon completion. When approved, the requirements listed in the VCD are verified and closed. 

1.4 Verification Hierarchy 

As requirements are allocated down the WBS levels, each lower level WBS verification supports 
the verification of that WBS level and its parent requirement’s verification. To ensure this 
verification hierarchy flow is not compromised, the responsibility of the RO at each WBS level 
is to ensure all of his/her assigned requirement verifications also support the parent 
requirement’s verification. However, the greater verification responsibility lies with a System 
level RO who is verifying the system and determining whether all verifications (including lower 
level WBS verifications) support the assigned system requirements. The System level RO 
declares his/her assigned system requirements are verified when the system level verifications 
and the lower WBS level allocated requirement verifications are approved. 

2 NPR 7123. 1A Process 

The Product Verification Process in NPR 7123. 1A can be found in section C.2.3: “The product 
verification process is used to demonstrate that an end product generated from product 
implementation or product integration conforms to its design solution definition requirements as 
a function of the product-line life-cycle phase and the location of the WBS model end product in 
the system structure. Special attention is given to demonstrating satisfaction of the Measure of 
Performances (MOPs) defined for each Measure of Effectiveness (MOE). ” 
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“A typical process flow diagram for product verification is provided in Figure 2 (Figure C-8 
from NPR 7 123.1 A) with inputs and his/her sources and the outputs and his/her destinations. The 
activities of the product verification process are truncated to indicate the action and object of the 
action. ” 

Figure 2 illustrates the Product Verification Process as defined in section C.2.3.4 of NPR 
7123.1 A. The figure shows the requirement verification activities that the Requirement 
Assurance process must meet. 


2.1 Product Verification Process 


From Product 


Activity f 


From Configuration 
Management Process 


Specified Requirements 
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C.2.3.2b 


From Design Solution and 
Technical Planning Processes 


Product Verification Plan 
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C.2.3.2d 


Perform Product Verification 
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Product Verification Results 
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Management Process 


Product Verification Results 
C.2.3.3c 


Product Verification Work 
Products 


Figure 2 - NPR 7123-1A Product Verification Process 

(* NPR 7 123-1 A section number) 


3 Requirement Assurance Process 

The Requirement Assurance (RA) process is a product requirement verification process that 
allows the WBS level system engineers to create a verification process that can be scaled to fit 

the project size and tailored to meet the project needs. The RA process is mapped (Figure 3) to 

f 

its applicable NPR 7 123.1 A Activity which demonstrates the RA process is in compliance with 
the guiding document. 
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3.1 Requirement Owner 

Every requirement has a Requirement Owner (RO) assigned by the WBS level project manager. 
The RO is considered the subject matter expert of that requirement and is responsible to ensure 
assigned requirements are verified. The RO can delegate the responsibility to perform/record the 
verifications for which he/she is responsible. When the VCS is completed, the RO reviews it for 
completeness and accuracy and approves the closure artifacts as the conclusive proof/evidence 
necessary to verify the requirement. The RO submits the VCS to the WBS level system engineer 
for verification approval. 


C.2.3.4a C.2.3.4b C.2.3.4c 



C.2.3.4d C.2.3.4e 



SE submits the 
VCD to the project 
for closure 
approval 



Figure 3 - NPR 7123. 1A and Requirement Assurance Process Integration 
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3.2 Product Verification Preparation 

In preparing to conduct requirement verifications, NPR 7123.1 A section C. 2. 3.4a directions 
suggest the following: 

“(1) reviewing the verification plan for any specific procedures, constraints, conditions 
under which verification will take place, pre- and post-verification actions, and criteria for 
determining the success or failure of verification methods and procedures; 

(2) arranging the needed product-verification enabling products and support resources; 

(3) obtaining the end product to be verified; 

(4) obtaining the specification and configuration baseline against which the verification is to 
be made; and 

(5) establishing and checking the verification environment to ensure readiness for 
performing the verification. ” 

In the Requirement Assurance process, the verification phase does not begin until the 
requirement document and verification plan have been approved. The suggested review topics in 
(1) above are conducted as a part of the verification event planning effort. 

Directions given in (2), (3), and (4) occur during the initial planning of the verification method 
activity and are added to the verification method’s procedure(s) as a check-off. The evidence of 
meeting (2), (3), and (4) in section C.2.3.4a is found in the closure documentation (procedure, 
process, checklist, etc.). 

3.2.1 Verification Matrix 

The Verification Matrix (VMX) (Appendix B - Figure Bl) is a document that contains all the 
requirement pre-verification data needed to perform the requirement verification. It establishes 
the verification scope (requirement), success criteria, rational, traces, and environments of who, 
what, when, and where the verification event is to occur. The VMX is an optional document 1 
depending on the verification strategy of the project. The RO is responsible to provide the pre- 
verification data and the system engineer works collaboratively with the RO. Once submitted, 
the system engineer can directly populate the VCSs, or uses the VMX as suggested to hold all 
the pre-verification data and mail merges it into the VCS. If the project is small, the system 
engineer can develop the VMX directly into a VCD. 

To fulfill (5) of section C.2.3.4a ( establishing and checking the verification environment to 
ensure readiness for performing the verification), a VMX is constructed at each WBS level using 
a spreadsheet. The VMX should not be confused with the Verification Cross Reference Matrix 
found in a WBS level requirement document. When the VMX is fully populated with pre- 
verification data, the WBS level system engineer can submit the VMX to the project to baseline 
all the pre-verification data. Another example of a VMX is found in reference 2 in Appendix D. 


1 This SP assumes the Verification Matrix (VMX) is being used to hold pre-verification data. 
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From section C.2.3.3c, the VMX will have a minimum set of pre-verification information for 
each product requirement verification: 

“(1) the source paragraph references from the baseline documents for derived technical 
requirements, technical requirements, and stakeholder expectations; 

(2) bidirectional traceability among these sources (NOTE: The system engineer can place 
traces to IRDs or ICDs); 

(3) verification type(s) to be used in performing verification of the specified requirement ; 

(4) reference to any special equipment, conditions, or procedures for performing the 
verification 

(5) verification scope (verification requirement); 

(6) verification success criteria (containing any MOPs or MOEs); 

(7) the approximate date when the closure artifact/document will be available; 

(8) anticipated scheduled occurrence of the verification event; 

(9) requirement number; 

(10) requirement text; 

(11) requirement owner’s name; and 

(12) any other information the system engineer requires such as a verification rationale. 
3.2.2 Verification Compliance Sheet 

When the project approves the requirement pre- verification data in the VMX, the system 
engineer accomplishes a simple mail merge between the VMX spreadsheet and the word 
processor’s VCS which populates the VCS with all the required pre-verification information. 
The system engineer collates the pre-verification VCSs by RO and places them in an electronic 
workbook (typically a Microsoft Word file) specific for each RO. A pre-verification VCS is 
observed in Appendix A, Figure A-l. 

When the verification event occurs and the VCS is populated with the final verification 
information (Result Summary and Closure Artifacts/Document sections, etc.), it becomes the 
requirement’s verification approval/closure documentation. As the RO or designee completes 
the VCS, the amount or type of data presented in the VCS, as seen in Appendix A, Figures A-2 
through A-5, is unrestricted. The RO approves each closure artifact and reviews the VCS prior 
to sending it to the WBS level system engineer for verification approval. 
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3.2.3 Workbook 

The workbook is an unofficial working level word processing document (typically Microsoft 
Word) created by the system engineer for the RO. The workbook contains all the RO’s assigned 
verifications as VCSs as well as any other supportive information. These YCSs are first 
populated with the required pre-verification data and then placed in the workbook. The 
workbook allows the RO to record, highlight, add working notes, and any information deemed 
necessary to support the verification of a requirement. 

3.2.4 Cross Reference Table 

Prior to a verification event such as testing, concurrence by the RO or his/her designee should be 
required in the procedure’s or process’s signature page which signifies that all applicable 
requirements for that event are identified and included in the procedure or process. A table 
should exist in the procedure or process similar to the Cross Reference Table example seen in 
Table 1 below that identifies the requirement and where its verification is located. 


Requirement 
Number being 
Verified 

Closure Document 
Page Number 

Closure 

Document 

Section 

Closure Document 
Procedure Step 
Number 

AI1-CML-009 

14 

1.2.3 

N/A 

DTO2-AV-1029 

17 

3.2.4.1a 

25 and 26 

HYT-008 

35 

4. 5. 1.2. e 

3 


Table 1 - Cross Reference Table Example 
3.3 Product Verification Execution 

In accordance with NPR-7123.1A section C.2.3.4b: “ Perform the product verification in 
accordance with the product verification plan and defined procedures to collect data on each 
specified requirement with specific attention given to Measure of Performance (MOPs)P 

When the verification event occurs, its outcome is measured against the requirement’s 
verification success criteria found in the VCS’s Verification Success Criteria section. Upon the 
event’s conclusion, the RO takes the workbook and completes the Result Summary and Closure 
Artifact/Document sections in the VCS. When the closure document (“as run” procedure, signed 
off reports, “as built drawings”, etc.) or closure artifact becomes available, the RO places a copy 
of it onto the project’s server and adds its filename and server URL to the Closure 
Artifact/Document section of the VCS (Appendix A, Figure A4). Once the VCS is completed 
and the RO has approved the closure artifact(s) or document, the VCS is submitted to the system 
engineer for verification approval. 
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3.4 Product Verification Analysis of Outcomes 

In accordance with NPR-7123.1A section C.2.3.4c: “ Analyze the outcomes of the product 
verification, including identifying verification anomalies, establishing recommended corrective 
actions, and establishing conformance to each specified requirement under controlled 
conditions. ” 

Further direction is given from section 2.3.3c of the NPR-7123.1A, “. ..(5) results of verification 
conducted; (6) variations, anomalies, or out-of-compliance results; (7) corrective actions taken; 
and (8) results of corrective actions. ” 

The verification outcome analysis occurs following the completion of the verification event 
where the results are compared to the verification success criteria. When the analysis and 
comparisons are completed, the RO writes the results in the VCS Results Summary section. If a 
discrepancy or non-conformance is found, then it is entered in the WBS level non-conformance 
resolution process for corrective action. The VCS is left open until resolution. 

3. 4. 1 Discrepancy or Non-Conformances 

When the verification outcome is compared to the success criteria and the verification anomalies 
are observed, the RO ensures the product is entered into a recognized institutional non- 
conformance process which establishes corrective actions that must occur prior to the approval 
of the product/requirement verification. 

All non-conformances and discrepancies such as any procedural, equipment, operator or setup 
problems, etc., are annotated in the requirement’s VCS “NFR” section. The requirement cannot 
be verified until all non-conformances have been officially closed by corrective action or by an 
approved variance (waiver or deviation). Non-conformance and discrepancy actions and results 
are placed in the Results Summary section of the VCS by the RO. 

3. 4. 2 Closure Artifacts 

The closure artifact is the conclusive and indisputable evidence used during the outcome analysis 
that proves the requirement verification. Closure artifacts are stand alone “artifacts” or found in 
a closure document. These closure documents may be test, analysis or demonstration reports, 
“as-run” procedures, ”as built” drawings, and in some cases, photographs. However, design 
drawings and procedures without signatures or Quality Assurance sign-offs are not acceptable as 
closure documents or artifacts. The closure artifact and document references are found in the 
Closure Artifact/Document section of the VCS. 

3.4.3 Result Summary 

The Requirement Owner or designee writes a summary of the verification result of each test, 
analysis, demonstration, inspection, corrective actions, etc., for that requirement. It should make 
“ reference to any special equipment, conditions, or procedures for performing the verification. ” 
Enough written information should be evident so the reader has a basic understanding of what 
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occurred for this requirement’s verification. The RO is not restricted on the type of information 
or the use of references included or the length of this section. 

3.5 Product Verification Report Preparation 

In accordance with NPR-7123.1A section C.2.3.4d: “ Prepare a product verification report 
providing the evidence of product conformance with the applicable design solution definition 
specified requirements baseline to which the product was generated, including bidirectional 
requirements traceability and actions taken to correct anomalies of verification results. ” 

To meet this guidance, the Verification Compliance Document (VCD) is developed using 
information from section C.2.3.4d. The recommended content of this document (report) can be 
found in section 2.3.3c. of NPR-7123.1A. 

3.5.1 Verification Compliance Document 

When the verification data matures and the closure artifacts are approved, the RO completes and 
delivers the VCS to the system engineer for verification approval. The WBS level system 
engineer reviews the information on the VCS for completeness, accuracy, and details, and the 
closure artifacts for approval. If the system engineer cannot approve the VCS, the system 
engineer works with the RO to resolve any issues such that the requirement verification obtains 
approval. 

After all the VCSs have been submitted and approved by the system engineer, the Verification 
Compliance Document (VCD) is developed by the WBS level system engineer by placing the 
approved VCSs within the document. The system engineer submits the VCD to the appropriate 
WBS level approval authority for baselining. After baselining, the requirements and closure 
artifacts are closed. 


3.6 Work Product Capture 

In accordance with NPR-7123.1A section C.2.3.4e: “Capture the work products from the 
product verification. Note: Work products include verification outcomes; records of procedural 
steps taken against planned procedures; any failures or anomalies in the planned verification 
procedures, equipment, or environment; and records citing satisfaction or non-satisfaction of 
verification criteria. Also, records should document: 

(1) the version of the set of specification and configuration documentation used; 

(2) the version of the end product verified; 

(3) the version or standard for tools and equipment used, together with applicable 
calibration data; 

(4) results of each verification including pass or fail declarations; and 

(5) discrepancies between expected and actual results. ” 
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The products listed from section C.2.3.4e and seen from (1) through (5) are found in the VCD. 
When a VCD is approved and baselined, all closure artifacts and documents are made available 
and archived in accordance with the WBS level data management or verification plan. 

4 Conclusion 

The Requirement Assurance process presented provides the system engineering practitioner a 
process that ensures product requirement verification that meets NPR 72 13.1 A direction. This 
process is mapped into the NPR 7213. 1A section C.2.3 - Product Verification Process which 
provides a confidence of applicability. The Requirement Assurance verification process defines 
and demonstrates how the process components fit within each Activity in section C.2.3. This 
verification process easily allows product requirement verification to occur on one Verification 
Compliance Sheet or multiple continuation sheets. In addition to its effectiveness, this method 
can be scaled to any size project and tailored for any WBS level (system, element, subsystem, 
etc.). This process integrates with industry standard requirements and Systems Engineering 
tools. 
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Definitions 


Applicable documents: - Further sources of detailed information for meeting this verification 
(e.g., NASA test or analysis standards, project documents, etc.) 

Closure Artifact: - This is the basic datum that is the conclusive proof or evidence by which the 
requirement is verified and closed. A closure artifact can be where a MOP or MOE has clearly 
shown with independent assurance (typically a Quality Assurance sign-off) has been met. The 
closure artifact is under configuration control and cannot change. In some rare instances, the 
closure artifact can be the closure document (i.e. inspection sheet). 

Closure Documents: - A document that contain the closure artifact(s) used to conclusively 
prove the requirement was verified, closure documents include test reports, analysis reports, 
inspection reports, and as-run procedures, as-built drawings, etc. In some rare instances, the 
closure document can be the closure artifact (i.e. test report or “as run” procedure). 

Measure of Effectiveness (MOE): - A measure by which a stakeholder’s expectations are 
judged in assessing satisfaction with products and systems produced and delivered in accordance 
with the associated technical effort. The MOE is deemed to be critical to not only the 
acceptability of the product by the stakeholder, but also critical to the operational / mission 
usage. An MOE is typically qualitative in nature or not able to be used directly as a “design-to” 
requirement. 

Measure of Performance (MOP): - A quantitative measure that, when met by the design 
solution, will help ensure that an MOE for a product or system will be satisfied. These MOPs are 
given special attention during design to ensure that the MOEs to which they are associated are 
met. There are generally two or more measures of performance for each MOE. 

NFR: - This is a non-conformance report written against a verification anomaly which must have 
corrective action done prior to verification approval. 

Requirement Owner: - This person is the subject matter expert of his/her assigned 
requirements. They’re also responsible to ensure assigned requirements are verified. They also 
approve closure artifacts. 

Scheduled Activity: - The activity on the project schedule where the verification event should 
occur. The verification event does not necessarily need to be scheduled on the project schedule, 
just tied to and existing one. This information is used to help manage verification activities 
where there may be multiple verifications occurring at a single facility or resource. This 
information is not used to measure performance or delivery dates. 

Verification Rationale: - An explanation and justification for “why” the specific method, 
success criterion, measure, constraints, conditions, and assumptions were stated. 

Verification Scope or Requirement: - Description of the work to be performed, described in 
one or more “shall” statements (requirements) stating the measure (a parameter, quantity, or 
condition) for the verification success criterion. This part should state how to obtain (generally, 
not calling out a specific tool) values or states for this measure. This part may state required 
assumptions and conditions for the verification. 
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Verification Success Criteria: - A single “shall” statement (requirement) stating the required 
criterion (MOPs/MOEs) for the verification to be considered successful in terms of the measure 
for the success criterion. 

WBS level: - Level(s) of assembly at which the requirement will be verified (e.g., system, 
element, subsystem, etc.). 
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Appendix A: Verification Compliance Sheet Examples 

Appendix A contains example of VCSs. Figure A-l is an example of a VCS completed with 
only “pre-verification data” that goes into the Requirement Owner’s workbook. Figures A-2 
through A- 5 are examples of a completed VCS of different project sizes and WBS levels. 

Figure A-l 

Verification Compliance Sheet (Workbook Example) 
Populated with Pre- Verification Data 

Requirement Title: Requirement No.: Verification Method. 

Bending Stiffness Profile CML-062 Analysis 

Requirement Text: The CM/LAS Parent Rqmt: 

bending stiffness shall be within +/- FTV-008, Oil 

10% of the El profile shown in the 
CM/LAS portion of the SRD 
requirement FTV-008. 


Description of Verification Activity (Verification Scope): CM/LAS personnel shall show by 
analysis found in AI1-CML-SAR-CM that the joint stiffness between the CM/LAS and USS is 
greater than 20% of the adjacent sectional bending stiffness. 

Note: USS personnel will also analyze this joint since it is shared between the CM/LAS and USS 
IPTs (Requirement ICMLAS-USS.003 in AI1-IRD-C2U). The CM/LAS analysis results will be 
compared with those obtained by Upper Stage Simulator (USS). Modal test data obtained by 
SE&I for the Stack 5 hardware in the VAB will provide additional, corroborating information for 
these analyses. 


Verification Success Criteria : The verification shall be successful when the joint stiffness 
between the CM/LAS and USS is shown by analysis to be greater than 20% of the adjacent 
sectional bending stiffness and the CM/LAS results compare well with the USS results. 

Rationale: Simulation using independent and validated analysis tools and techniques (by both 
CM/LAS and USS IPTs) is an accepted method to verify requirements for such properties that 
can only be accurately tested at an assembly level. Modal test data for Stack 5 at KSC will be 
available from SE&I to substantiate the analysis results. 
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Figure A-2 (Large Project Example) 
Verification Compliance Sheet (System level) 


Ares I-X FTV System 
Verification Requirement Definition Sheet 



Verification 

Number: 


FTV SRD Requirement to be Verified 


Requirement Number: 


VR-FTV-001 


Requirement Title: FTV Elements 


FTV-001 


Verification Requirements 

Verification method: Verification that the FTV consists of the following elements (CM/LAS, USS, RoCS, FS, 
& Avionics) shall be by Inspection. 

Description of verification activities to be performed: 


The Ares I-X Vehicle Assembly and Integration Lead will review final designs that have been 
approved at the Ares I-X CDR to verify inclusion of the five listed elements. 


The Ares I-X Interface Custodians shall review artifacts from each IPT showing compliance with 
his/her side of the interfaces defined in the applicable Element to Element IRD. When all element- 
level interface requirements associated with an Element to Element IRD have been verified to his/her 
satisfaction, each Interface Custodian shall provide a summary of the interface verifications to the 
Ares I-X Lead Systems Engineer. The summary report shall include any waivers or deviations to the 
interface requirements. 


The Ares I-X Lead Systems Engineer shall review the interface verification summary reports and the 
integrated vehicle drawing to verify that the FTV is constructed from the five elements listed. 

Success Criterion: 

CDR approved design of the Ares I-X FTV includes the five elements listed in FTV-001 and Interface 
Verification Summary Reports for all Element to Element IRDs. 

Rationale: 

Verification by inspection of CDR designs is appropriate for the requirement. 


Verification Implementation 
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Level: The Ares I-X FTV System does comply with FTV-001. See attached compliance statement. 

Applicable documents: 

CDR Data from all FTV IPTs. 

Nonconformance history: List any waivers below; address them later in the compliance statement. 

• CR-AIX-0344 “CM/LAS CM Flange Flatness Local Exceedance. (AIX-IRD-C2U [ICMLAS- 
USS.001.5] Flatness)” 

• CR-AIX-0359 “USS SM to CM/LAS Mechanical Interface” 

• CR-AIX-0363 “USS US-1 US RCS Cover Protuberance Pressure Transducer with No 
Bonding Check” 

• Plus 50 Element IRD/ICD waivers, listed in the Interface Custodian Verification Summary 

reports in Section 1.2 

Closure data/documentation required: 

Electronic/Written confirmation from the Ares I-X Lead Systems Engineer that the approved CDR 
design includes the required elements and that the element to element interfaces have been verified. 

Event preceding Verification Activity: 

Element to Element Interface Requirements are closed. 


Estimated Duration of Verification Activity: 5 Days 


Closure Of FTV SRD Requirement 

Requirement Owner: 

Systems Engineer: 

Technical Management Approval: 

Richard Harris 

(with compliance statement write-up support 
from Paul Luz) 

Cheryl Harrison 

Joe Smith 



S&MA Approval: 


SE&I Lead Engineer Approval: 

Date Closed: 







Dave Jones 

Stewart Long 


Compliance Evaluation for Ares I-X Verification Number: VR-FTV-001 “FTV Elements” 

The Ares I-X FTV is in compliance with requirement FTV-001, “The FTV shall consist of the 
following five elements: FS, USS, CM/LAS, Avionics, and RoCS .” A summary of the analysis 
and a review of verification artifacts are provided below. 

The design snapshot below and photographic evidence on the next page show compliance with 
paragraph 1 of 3 in the Verification Requirement Definition Sheet (VRDS) for requirement VR- 
FTV-001, which states, “The Ares I-X Vehicle Assembly and Integration Lead will review final 
designs that have been approved at the Ares I-X CDR to verify inclusion of the five listed 
elements.” 
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Ares I-X High Level Poster/Drawing 


E-mail from Bruce Askins, the Ares I-X Project Integration Manager, “77ze high level Ares I-X 
posted has been updated to reflect the configuration and detail as of 9/1/08 by Jonathan Behun 
with contributions from Terry White and Roosevelt Wright. It is set-up where it can be printed 
as a 22 x 36 poster. 2 


Ares I-X top level assembly drawing is 1264846. 


Ares I-X Flight Test Vehicle 




' 




I I I 
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NASA KSC Media Photo release KSC-2009-4954 on August 31, 2009 

“CAPE CANA VERAL, Fla. - Work platforms surround the Ares I-X launch vehicle in the 
Vehicle Assembly Building's High Bay 4 at NASA 's Kennedy Space Center in Florida. The rocket 
has undergone a sway test that simulated conditions the rocket could experience during rollout 
to Launch Pad 39B... ’’ 


2 Ares I-X Project Integration Manager Bruce Askins, e-mail to NASA-DL-AresIX-Primary-Contacts distribution 
list, “Ares I-X High Level Poster/Drawing Update”, September 22, 2008 at 6:39 AM. 


18 



Bottom line: All 5 elements have been delivered and assembled, demonstrating that requirement 
FTV-001 has been fulfilled. For a summary recap that lists when each element was delivered, 
please see Section 5.0. 


Paragraph 2 of 3 in the VRDS for FTV-001 states, “The Ares I-X Interface Custodians shall 
review artifacts from each IPT showing compliance with his/her side of the interfaces defined in 
the applicable Element to Element IRE). When all element-level interface requirements 
associated with an Element to Element IRD have been verified to his/her satisfaction, each 
Interface Custodian shall provide a summary of the interface verifications to the Ares I-X Lead 
Systems Engineer. The summary report shall include any waivers or deviations to the interface 
requirements." 
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Interface Requirement 
Documents (IRDs) 

Interface Custodian 

Delivery Date 

Interface Custodian’s Summary Report 
delivered to the Ares I-X LSE 

USS to CM/LAS 
(AI 1 -IRD-C2U v3.01) 

LaRC/ Mark McMillin 

2009-10-16 via e-mail, AI1-SYS-IVSR. 

3 CM/LAS waivers, ah were approved by 
XCB. 

USS to Roll Control 
(AI1-IRD-R2U v2 04) 

LaRC/ Mark McMillin 

2009-10-16 via e-mail, AI1-SYS-IVSR. 

3 RoCS waivers, all were approved by XCB. 

USS to First Stage 
(AI1-IRD-U2F v2.02) 

LaRC/ Mark McMillin 

2009-10-16 via e-mail, AI1-SYS-IVSR. 
4 FS waivers, all were approved by XCB. 

Flight Test Vehicle to 
Ground Systems 

(AI1-IRD-F2G v5.05) 

JSC / Jim Wiehoff 

2009-10-20 

9 GS waivers, ah were approved by XCB. 

Avionics to Ground 
System (AI1-IRD-F2G 
Appendix I v5.05) 

LaRC / Jose Ortiz 

2009-10-13 via e-mail. 

1 waiver; it was approved by XCB. 

Lockheed Martin Ground 
Command, Control, 
Communications (GC3) 
To NASA Ground 
Element (AI1-IRD-F2G 
Appendix II v5.05) 

LaRC / Jose Ortiz 

2009-10-13 via e-mail. 

1 waiver; it was approved by XCB. 

Avionics to Flight Vehicle 
Elements 

(AI1-ICD-A2V v5.0) 

LaRC / Jose Ortiz 

2009-10-13 via e-mail. 

28 waivers, ah were approved by XCB. 


Paragraph 3 of 3 in the VRDS for FTV-001 states, “The Ares I-XLead Systems Engineer shall 
review the interface verification summary reports and the integrated vehicle drawing to verify 
that the FTV is constructed from the five elements listed.” 

In regard to the LSE review of interface verification summary reports is covered by XCB 
Approval. 

In regard to the LSE review of the integrated vehicle drawing to verify that the FTV is 
constructed from the five elements listed, please see the drawing and photograph provided within 
Section 1.1. Bottom line: All 5 elements have been delivered and assembled, demonstrating that 
requirement FTV-001 has been fulfilled. For a summary recap that lists when each element was 
delivered, please see Section 5.0. 
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Requirement Recap 

Ares I-X requirement FTV-001 is documented in the “System Requirements Document for the 
Ares I-X Flight Test Vehicle”, AI1-SYS-SRD v4.15a, December 7, 2008, pp28-29: 


42.1.1 FTV-001 : FTY Elements 

• The FTY shall consist of the following five elements: FS : USS, CM LAS, Avionics, and 
RoCS. 

28 


Ares I-X Flight Test 

Title Ares I-X Flight Test Vehicle 
System Requirements D ocument 

Document Xo: AIl-SYS-SRD'-VER 4.15 

Baseline 

E ff e ctiv e Date: Dec. 07 ; 200 S 

Page 29 of 103 


[Rationale: The FTVis a developmental model for the CLVAres TOrion. Significant 
planning and analysis has been done around these functional elements. This architecture is 
inferred in the FTP in Sections 3 and 5. In order to be similar to the Ares 1/Orion, these 
elements are mandated by the Ares l- 1 flight test] 

[Trace: P1-P5, S1-S7] 

[Allocation: All elements] 

[Priority: 1] 
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Trace Analysis 

Table 3.0-1 IPT Children Requirements that were traced to SRD Requirement FTV-001 


Child Reqmt 

Title 

Disposition 

CML 



CML-001 

CM/LAS Sub-Elements 

Submitted to the XCB via CR-AIX-0435. 

Approved by XCB 20090625 

RA VEN comment: “ Closed 9/24 per Barry ” 

RoCS 



RoCS-037 

RoCS Installation 

Submitted to the XCB via CR-AIX-0313. 
Approved by XCB 20090605. 

RoCS-039 

RoCS Ordnance 

RoCS-040 

RoCS Engine 

uss 



USS-001 

USS Element Simulators 

Submitted to the XCB via CR-AIX-0318. 
Approved by XCB 20090331 

USS-041 

RoCS Interfaces 

Submitted to the XCB via CR-AIX-0463. 
Approved by XCB 20090728. 

USS-053 

FS Mechanical Interfaces 

Submitted to the XCB via CR-AIX-0570. 
Approved by XCB 20090929. 

USS-054 

CM/LAS to USS Mech. 
Interfaces 

Submitted to the XCB via CR-AIX-0463. 
Approved by XCB 20090728 

USS-055 

Avionics Structural Interfaces 

Submitted to the XCB via CR-AIX-0570. 
Approved by XCB 20090929. 

USS-056 

Avionics G&B Interfaces 

USS-115 

FS to USS Interface Markings 

Submitted to the XCB via CR-AIX-0377. 
Approved by XCB #USSAR (XCB 20090505). 

USS-117 

FS Human Access 

Submitted to the XCB via CR-AIX-0570. 
Approved by XCB 20090929. 

USS-118 

CM/LAS to USS Interface 
Markings 

Submitted to the XCB via CR-AIX-0348. 
Approved by XCB 20090421 

USS-119 

CM/LAS to USS Human Access 

USS-120 

RoCS to USS Electrical Bonding 

Submitted to the XCB via CR-AIX-0377. 
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Child Reqmt 

Title 

Disposition 

USS-121 

FS to USS Electrical Bonding 

Approved by XCB #USS AR (XCB 20090505). 

USS-122 

CM/LAS to USS Electrical 
Bonding 

Submitted to the XCB via CR-AIX-0348. 
Approved by XCB 20090421 

USS-124 

RoCS Mass Interface 

Submitted to the XCB via CR-AIX-0377. 
Approved by XCB #USS AR (XCB 20090505). 

USS-125 

RoCS Human Access Interface 

Submitted to the XCB via CR-AIX-0377. 
Approved by XCB MJSSAR (XCB 20090505). 

AVI 



AVI-200 

Avionics [Baseline] 

Submitted to the XCB via CR-AIX-0372. 
Approved by XCB 20090428. 

AVI-208 

USS Electrical [Baseline] 

Submitted to the XCB via CR-AIX-0627. 
Approved by XCB 20091020 

AVI-209 

CM/LAS-Electrical [Baseline] 

Submitted to the XCB via CR-AIX-0404. 
Approved by XCB OSB on 20090803. 

AVI-210 

First Stage-Electrical [Baseline] 

Submitted to the XCB via CR-AIX-0627. 
Approved by XCB 20091020 

AVI-215 

USS-Physical [Baseline] 

Submitted to the XCB via CR-AIX-0627. 
Approved by XCB 20091020 

AVI-216 

CM/LAS-Physical [Baseline] 

Submitted to the XCB via CR-AIX-0404. 
Approved by XCB OSB on 20090803 

AVI-217 

First Stage-Physical [Baseline] 

Submitted to the XCB via CR-AIX-0574. 
Approved by XCB 20091006. 

AVI-242 

FSAM [Baseline] 

Submitted to the XCB via CR-AIX-0627. 
Approved by XCB 20091020 

AVI-261 

RoCS-Physical [Baseline] 

Submitted to the XCB via CR-AIX-0453. 
Approved by XCB OSB on 7-27-2009. 

AVI-262 

RoCS-Electrical [Baseline] 

Submitted to the XCB via CR-AIX-0627. 
Approved by XCB 20091020 

FS 
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Child Reqmt 

Title 

Disposition 

FS-001 

RSRM 

Submitted to the XCB via CR-AIX-0583. 

FS-002 

FS Safe and Arm System 

Submitted to the XCB via CR-AIX-0508. 

FS-003 

System Tunnel 

Submitted to the XCB via CR-AIX-0554. 

FS-004 

Aft Skirt Assembly 

Submitted to the XCB via CR-AIX-0583. 

FS-005 

Thrust Vector Control 

Submitted to the XCB via CR-AIX-0554 
(Electrical) and also CR-AIX-0618 (Interstage). 

FS-008 

First Stage Deceleration 
Subsystem 

Submitted to the XCB via CR-AIX-0554. 

FS-009 

Nosecap 

Submitted to the XCB via CR-AIX-0560. 

FS-010 

Thrusters 

Submitted to the XCB via CR-AIX-0624. 

FS-012 

Parachutes 

Submitted to the XCB via CR-AIX-0518. 

FS-013 

Booster Deceleration/Tumble 
Motor 

Submitted to the XCB via CR-AIX-0469. 

RAVEN comment: “A-PYR-61 24-7/1 0PLN- 
0060A-Baselined” 

FS-206 

Ignition Separation Controller 

Submitted to the XCB via CR-AIX-0605. 

FS-207 

Recovery Controller Unit 

Submitted to the XCB via CR-AIX-0605. 

FS-208 

Heritage Altitude Switch 
Assembly 

Submitted to the XCB via CR-AIX-0605. 

FS-209 

APUC Heritage 

Submitted to the XCB via CR-AIX-0605. 

FS-210 

ISC Interface 

Submitted to the XCB via CR-AIX-0605. 

FS-211 

RCU Interface 

Submitted to the XCB via CR-AIX-0605. 

FS-212 

SRB Heritage ASA 

Submitted to the XCB via CR-AIX-0605. 


NOTE: FS verifications are considered approved upon receipt of the CR per MMO directive 
CR-AIX-0537. 

There is a subfolder for each XCB that was held. The CR’s are in the folder that corresponds to 
the date the XCB was held. For example, the RoCS IPT CR-AIX-0313 can be found in folder 
“XCB 20090605”. 


Waivers against FTV-001 

This section only identifies and discusses the system-level waivers that were written directly against 
system-level verification requirement FTV-001 in the “System Requirements Document for the Ares I-X 
Flight Test Vehicle”, AI1-SYS-SRD v4.15a, December 7, 2008, pp28-29. 
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For a review of the element-level IRD/ICD waivers (these were waivers to the IRDs and not waivers to 

AI1-SYS-SRD), please see the Interface Custodian Verification Summary reports listed in Section 1.2. 

There were 50 IRD/ICD waivers from the elements, all of which were approved by the XCB. 

CR-AIX-0344 “ CM/LAS CM Flange Flatness Local Exceedance (AIX-IRD-C2U [ICMLAS- 

USS.001.5J Flatness)” 

• This waiver was traced to requirements FTV-001 and AI1-IRD-C2U v3.00, Section 4.1.1 
Mechanical Assembly Joint, Requirement [ICMLAS-USS.001.5] - Flatness. 

• The waiver was “Approved as presented” by XCB 20090512. 

• Qmclusion : Given that this waiver really affects an IRD requirement and not the higher 
system-level requirement FTV-001, “The FTV shall consist of the following five elements: 
FS, USS, CM/LAS, Avionics, and RoCS”; and given that the waiver was approved by the 
XCB in any case; the waiver therefore does not impact the verification of FTV-001 . 

CR-AIX-0359 “ USS SM to CM/LAS Mechanical Interface ” 

• This waiver was traced to requirements USS-054. One could argue that this waiver is 
also relevant to the verification of FTV-101 “Stack/Destack Assembly Joints”. The 
verification compliance statement for FTV-101 already does include an evaluation of this 
waiver for completeness. 

• The waiver was submitted "... to communicate several non-conformances to the SM 
segment top flange mechanical interface as documented in the CM/LAS to USS IRD, AI1- 
IRD-C2U ’, and specifically “ Flange local flatness, Tension bolt hole spotface 
depth/flange thickness, Flange O.D. tolerance ”. 

• The waiver was “Approved as presented” by XCB 20090512. 

• Furthermore, Ares I-X finished stacking CM/LAS onto USS on August 13, 2009. 

• Conclusion : Given that this waiver really affects requirement FTV-101 “Stack/Destack 
Assembly Joints ” and not requirement FTV-001, “The FTV shall consist of the following 
five elements: FS, USS, CM/LAS, Avionics, and RoCS”; and given that the waiver was 
approved by the XCB in any case; the waiver therefore does not impact the verification of 
FTV-001. ' 

CR-AIX-0363 “ USS US-1 US RCS Cover Protuberance Pressure Transducer with No 

Bonding Check ” 

• This waiver was elevated from CR-AIX-DXCB-0006 “USS US- 1 US RCS Cover 
Protuberance Pressure Transducer with No Bonding Check”. 

o The DXCB waiver traced to requirements FTV-001, USS-056, and AI1-ICD- 
A2V. 

o The DXCB waiver was submitted “. . .to communicate one non-conformance on 
the US-1 segment for the requirement to perform a bonding check on all DFI 
sensors that are installed into segment skins and the OML protuberances.” 
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o The DXCB waiver was “Approved” by DXCB Chair Lanny Upton on March 23, 
2009 and elevated to the XCB as CR-AIX-0363. 

• On April 7, 2009, XCB Secretariat Heather Altizer distributed an e-mail stating: 

o “CR AIX-0363 was withdrawn per email notification from DxCB secretariat.” 

o “Waiver was dispositioned at DxCB and upon futher investigation system level 
documents identified as affected products on the DxCB waiver were not 
affected.” 

• Conclusion : Given that this waiver was withdrawn, and given XCB statement above that 
“ ...upon further investigation system level documents identified as affected products on 
the DxCB waiver were not affected”; the waiver therefore does not impact the verification 
ofFTV-001. 
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Example A-3 (Large Project Example) 
Verification Compliance Sheet (Element Level) 


Verification No. ERD Requirement No. 

VR-CML-009 CML-009 


Requirement Title: Joint Stiffness 


Verification Method: Analysis 


Description of Verification Activity (Verification Scope): CM/LAS personnel shall show by 
analysis found in AI1-CML-SAR-CM that the joint stiffness between the CM/LAS and USS is 
greater than 20% of the adjacent sectional bending stiffness. 

Note: USS personnel will also analyze this joint since it is shared between the CM/LAS and USS 
IPTs (Requirement ICMLAS-USS.003 in AI1-IRD-C2U). The CM/LAS analysis results will be 
compared with those obtained by Upper Stage Simulator (USS). Modal test data obtained by 
SE&I for the Stack 5 hardware in the VAB will provide additional, corroborating information for 
these analyses. 


Verification Success Criteria: The verification shall be successful when the joint stiffness 
between the CM/LAS and USS is shown by analysis to be greater than 20% of the adjacent 
sectional bending stiffness and the CM/LAS results compare well with the USS results. 

Rationale: Simulation using independent and validated analysis tools and techniques (by both 
CM/LAS and USS IPTs) is an accepted method to verify requirements for such properties that 
can only be accurately tested at an assembly level. Modal test data for Stack 5 at KSC will be 
available from SE&I to substantiate the analysis results. 

~FTV-Trace: FTV-002, 004, 006, 009, 124 

Scheduled Activity: UID - 1591 Final Structural Analysis Doc Complete 
Closure Report No. : AI 1 -CML-S AR-CM 
AI1-IRD-C2U Trace: CMLAS-USS.003 
Requirement Owner: David Alexander 
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Figure A-4 (Medium Project Example) 
Verification Compliance Sheet (Subsystem Level) 


Requirement Title: 
Mounting 

Requirement No.: 

DT02-AV-1008 

Verification Method: 
Inspection 

Requirement Text: The Avionics 
Assembly shall mechanically 
interface to an Adaptive Payload 
Carrier (APC). 

Parent Rqmt: 
DTO1-SYS-1605 
DTO 1 -AVENC- 1 004 


Description of Verification Activity ( 
inspection that the Avionics Assembly 

Verification Scope): The Mechanical Lead shall verify by 
i is designed to mount to an APC carrier in Port side bay 3. 

Verification Success Criteria : The verification shall be succesful when: 

- the Avionics Enclosure meets the APC interface spec. 

- the Avionics mounting plate is fit checked with the APC carrier. 

Result Summary (Compliance Statement)): The AEA baseplate was fit checked to an APC at 
KSC and was found to fit correctly, prior to the buildup of the AEA. It was designed to the APC 
interface drawing given in ICD-A-21551, Figure 3. 0.4.2. 1.3. 1-1. 

Closure ArtifactZDocument(s): 

STORRM ICD-A-2 1551: http://www.unitedspacealliance.com/icd/RNS/contents.html 
STORRM Drawing 1 25063 7_REV_A AEA Mounting Plate dwg.pdf 
Fit check photos: SN -001 Picture l.jpg 

Waivers/ (NFRs): 
None 

Requirement Owner: 
Kevin Taylor 

Verification Closed 
3-1 6-201 0-MA 
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Figure A-5 (Small Project Example) 


Verification Compliance Sheet (System Level) 


Req. No. 

Requirement Title 

Verification 

method 

SRD No. 

VR-09 Spatia 

1 Resolution 

Analysis HYT 

■009 

Description oi 

by analysis of 
Rayleigh Crite 

Verification Activity (Verification Scope): HYTHIRM personnel shall show 
the Imaging Assets IR Imaging system is less than 1 8-inches per pixel using the 
ria. 

Success Criteria: The verification shall be successful when the analysis is confirmed and the 
Spatial Resolution is determined to be 18-inches per pixel or less. 

Result Summary (Compliance Statement): 

1) CAST GLANCE: I verify by Analysis of the calibration data and mathematical calculations 
that the Spatial Resolution is less than 18-inches per pixel. 

2) MARS: (Mobile Aerospace Reconnaissance System): 

Closure Artifact/Document(s):: 

1) APL HYTHIRM Radiance Modeling vl .5_vl_0.pdf 

2) STS- 125 ViDi MARS & CG Imagery Asset Placement 
4/28/2009.ppt 

Req. R.O.: 

Richard Harris 

NFR: 

None 

Applicable Documents: 
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Appendix B: Verification Matrix Example 


Figure B-l 


Verif 

No. 

REQ 

ID 

REQ 

TITLE 

REQ Text 

VM 

REQ 

OWNER 

Verification Scope 

Verification Success Criteria 

Verification Rational 

Scheduled 

Activity 

Verification Doc 

SYS Req 
Trace 

IRD/ 

ICD 

Trace 

VR-CML-0091 

CML-009 

Joint Stiffness 

• The joint stiffness between the CM/LAS and USS shall be 
greater than 20% of the adjacent sectional bending stiffness 
as set forth in section 4.1.3 Joint Stiffness of the document; 
Ares l-X Crew Module and Launch Abort System and Upper 
Stage Segment 1 nterface Requirement Document - Al 1-1 RD- 
C2U 

Analysis 

Harris 

CM/LAS personnel shall show by analysis found in Al 1-CML-SAR- 
CM that the joint stiffness between the CM/LAS and USS is greater 
than 20% of the adjacent sectional bending stiffness. 

:The verification shall be successful when the joint 
stiffness between the CM/LAS and USS is shown by 
analysis to be greater than 20% of the adjacent 
sectional bending stiffness and the CM/LAS results 
compare well with the USS results. 

Simulation using independent and validated 
analysis tools and techniques (by both CM/LAS 
and USS IPTs) is an accepted method to verify 
requirements for such properties that can only be 
accurately tested at an assembly level. Modal test 
data for Stack 5 at KSC will be available from SE&I 
to substantiate the analysis results 

UID - 1591 

Structural 
Analysis Doc 
Complet 

Al 1-CM L-SAR-CM 

FTV-002, 
004, 006, 
009, 124 

CMLAS- 

USS.003 

VR-CML-012 

CML-012 

Data Collection 

• The CM/LAS shall provide location and orientation of 
sensors as defined in the document All-SYS-DFI, DFI/OFI 
Measurement List 

Inspection 

Miller 

CM/LAS personnel shall show by reviewing the inspection reports 
of all DFI locations, orientations, alignments, and correct PSM ID# 
labeling of all CM/LAS sensors that they are in compliance with the 
document All-SYS-DFI, DFI/OFI Measurement List and approved 
drawings 

The verification shall be successful when CM/LAS 
personnel determine sensor location, orientation, and 
alignment coincide with those defined in the 
inspection reports, All-SYS-DFI and DFI/OFI 
Measurement list 

: Verification of the proper location, alignment, 
and correct PSM 1 D# labeling of all CM/LAS 
sensors is critical. Verification of the approved 
flight drawings and hardware will be performed 
by inspection of these items at the assembly level. 

UID-1521 - 
Rotate LAS 
to Vertical 
Position; 
Install on to 
CM 

All-CML-I P-001; As run 
procedure 
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Element Weight 

• The CM/LAS shall meet its unballasted mass allocation as 
stated in the Ares 1 -X Mass Allocation Baseline - Al 1-SYS- 
MAB 

Test 

Vo " e 

:CM/LAS personnel shall show by using a calibrated scale to weigh 
the CM and LAS assemblies that the CM/LAS meets the unballasted 
mass allocated in the Al 1-SYS-MAB. 

The verification shall be successful when the actual 
mass is demonstrated to meet the requirement. 

The mass requirement was generated by analysis, 
and the verification of the mass will be 
determined by lifting the CM and LAS. CM/LAS is 
weighing all the individual pieces/parts and some 
of the sub-assemblies. These data are used to 
verify the ProE model. 
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Individual Sub-Element 
Hoisting 

• The CM/LAS Simulator sub-elements shall have lifting 
points for vertical and horizontal handling. 

Demo 
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CM/LAS personnel shall demonstrate, by lifting and handling the CM 
and LAS, that the sub-elements have lifting points for vertical and 
horizontal handling. 

The verification shall be successful when the 
demonstration verifies the provision for the lifting 
points per the All-CML-AIT and conforms to the 
drawings. 

Demonstration is the most effective method to 
show compliance with the specification. 
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Workmanship (Electronics) 

• The CM/LAS shall comply with workmanship standards 
per NASA-STD-8739. 1-8739. 5, NASA series of 
Workmanship Standards, and ANSI/ESD s20.20. Protection 
of Electrical and Electronic Parts, Assemblies and Equipment 
(Excluding Electrically Initiated Explosive Devices) for non- 
heritage hardware. 
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Quality Assurance with CM/LAS personnel shall show by inspection 
of the workmanship that the CM/LAS complies with workmanship 
standards per NASA-STD-8739. 1-8739.5, NASA series of 
Workmanship Standards, and ANSI/ESD s20.20.** This inspection 
shall address QA inspection of cable installation, verification of 
termination, verification of workmanship related to bonding, 
grounding, and certification of compliance with s20.20 ESD 
processes. CM/LAS personnel shall perform liveness and 
continuity tests on all sensors. 

**CM/LAS is using NASA-STD-8739.7 in lieu of ANSI/ESD S20.20. 
Jose Otriz has concurred that 8739.7 meets the intent of S20.20, 
and no waiver is required. 

The verification shall be successful when inspection of 
the approved drawings and hardware demonstrates 
compliance with the specification and the ICD. 

1 nspection and test demonstrate compliance with 
the specification. 
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